What does this PR do?

Memoizes dc.channel(name) by name in patch-garbage-collection-bug.js, so subsequent calls for the same name always return the same Channel object regardless of what the underlying `channel()` returns. Also adds a regression test that pins the contract.

 module.exports = function(unpatched) {
   const dc_channel = unpatched.channel;
   const channels = new WeakSet();
+  const byName = new Map();

   const dc = { ...unpatched };

   dc.channel = function() {
+    const name = arguments[0];
+    if (byName.has(name)) return byName.get(name);
     const ch = dc_channel.apply(this, arguments);
+    byName.set(name, ch);

     if (channels.has(ch)) return ch;

Motivation

The PHONY_SUBSCRIBE anti-GC patch keeps a created Channel alive, but Node's underlying channel(name) can still return a brand-new Channel object for the same name on a subsequent call (observed on Node 18.20.8 under heavy workloads — e.g. proxyquire-driven reload of a tracer + plugin manager teardown/recreate cycles). The existing tracking — `channels = new WeakSet()` keyed by Channel-object identity — can't unify those: each new object isn't in the WeakSet, so dc-polyfill treats it as new, attaches its own phony, and returns it.

The visible failure mode for callers (a common instrumentation pattern):

// instrumentation module loaded once
const ch = dc.channel('foo')
shimmer.wrap(target, 'method', () => function () {
  if (!ch.hasSubscribers) return original.apply(this, arguments) // fast path
  ch.publish({ ... })
  return original.apply(this, arguments)
})

A separate consumer doing `dc.channel('foo').subscribe(...)` later may get a different Channel instance, attach its handler there, and never see publishes from the wrap — because the wrap's closure holds the earlier Channel. With only the phony left on the publish-side Channel, hasSubscribers returns false and the fast-path bypass kicks in. Publishes go nowhere.

Why this fix lives here, not upstream in Node

The underlying bug is in Node's diagnostics_channel registry — the right architectural home for the fix is Node itself. It is not realistic to land the fix there, however:

• The bug only manifests on Node 18. dc-polyfill's own hasFullSupport() check treats Node 20.6+ as fully supported (so this whole patch file is inert there). Empirically I see the same: dd-trace-js's reproducer triggers on Node 18.20.8 and not on Node 23.3.0 against the same code.
• The upstream fix that landed in Node 20.6 is referenced in this file's own comment: nodejs/node#47520. Whatever wider registry-stability fix(es) shipped alongside that resolved the symptom in 20.6+. There's no upstream gap to file a new PR against.
• Node 18 reached EOL on 2025-04-30 — over a year ago. Backports to EOL'd lines effectively only happen for security CVEs with active maintainer interest. "Diagnostic-channel returns inconsistent objects under specific workloads" wouldn't clear that bar, especially when a polyfill-layer workaround already exists.
• This whole patch file (`patch-garbage-collection-bug.js`) is gated by `hasGarbageCollectionBug()` and runs only on Node versions that have the bug. As consumers drop Node 18 support, this code path becomes inert and can eventually be deleted alongside the version checks. Patching at the polyfill layer is exactly what the polyfill is for.

Verification

• All existing dc-polyfill tests pass with the patch on Node 18.20.8 (`./test.sh`: 26/26 suites pre-existing, 27/27 with the new regression test).
• Lint clean (`npm run lint`).
• New regression test (test/garbage-collection-patch.spec.js) injects a mock `unpatched` whose `channel(name)` returns a different Channel each call — simulates the Node 18 misbehavior at the unit level. Fails 6/8 assertions on `main`, passes 8/8 with this patch. Covers identity stability, per-name memoization, and the subscribe/publish-across-calls case.
• Empirically verified end-to-end against dd-trace-js's ws plugin stress workflow (10 runners × 25 iterations on Node 18.20.8 — 250 runs total): 0/10 runners pass without this patch, 10/10 pass with it. Context PR: DataDog/dd-trace-js#8297.

Additional Notes

• The map is bounded by the number of unique channel names a process uses. In practice this is a small fixed set per process (per-instrumentation), so no meaningful retention concern.
• Doesn't conflict with the cross-version process-symbol registry in acquire-channel-registry.js — that registry sits at a different layer (shared tracingChannel wrappers across dc-polyfill versions); this patch makes the underlying per-version channel() results stable.
• Strengthens the contract callers already expect: `channel(name)` returns the channel for name. Doesn't weaken anything.

🤖 Generated with Claude Code